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Abstract 


Virtual Private LAN Service (VPLS), also known as Transparent LAN 
Service and Virtual Private Switched Network service, is a useful 
Service Provider offering. The service offers a Layer 2 Virtual 
Private Network (VPN); however, in the case of VPLS, the customers in 
the VPN are connected by a multipoint Ethernet LAN, in contrast to 
the usual Layer 2 VPNs, which are point-to-point in nature. 


This document describes the functions required to offer VPLS, a 


mechanism for signaling a VPLS, and rules for forwarding VPLS frames 
across a packet switched network. 
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1. Introduction 


Virtual Private LAN Service (VPLS), also known as Transparent LAN 
Service and Virtual Private Switched Network service, is a useful 
service offering. A Virtual Private LAN appears in (almost) all 
respects as an Ethernet LAN to customers of a Service Provider. 
However, in a VPLS, the customers are not all connected to a single 
LAN; the customers may be spread across a metro or wide area. In 
essence, a VPLS glues together several individual LANs across a 
packet switched network to appear and function as a single LAN [9]. 
This is accomplished by incorporating MAC address learning, flooding, 
and forwarding functions in the context of pseudowires that connect 
these individual LANs across the packet switched network. 


This document details the functions needed to offer VPLS, and then 
goes on to describe a mechanism for the auto-discovery of the 
endpoints of a VPLS as well as for signaling a VPLS. It also 
describes how VPLS frames are transported over tunnels across a 
packet switched network. The auto-discovery and signaling mechanism 
uses BGP as the control plane protocol. This document also briefly 
discusses deployment options, in particular, the notion of decoupling 
functions across devices. 


Alternative approaches include: [14], which allows one to build a 
Layer 2 VPN with Ethernet as the interconnect; and [13], which allows 
one to set up an Ethernet connection across a packet switched 
network. Both of these, however, offer point-to-point Ethernet 
services. What distinguishes VPLS from the above two is that a VPLS 
offers a multipoint service. A mechanism for setting up pseudowires 
for VPLS using the Label Distribution Protocol (LDP) is defined in 
[10]. 


1.1. Scope of This Document 


This document has four major parts: defining a VPLS functional model; 
defining a control plane for setting up VPLS; defining the data plane 
for VPLS (encapsulation and forwarding of data); and defining various 
deployment options. 


The functional model underlying VPLS is laid out in Section 2. This 
describes the service being offered, the network components that 
interact to provide the service, and at a high level their 
interactions. 


The control plane described in this document uses Multiprotocol BGP 
[4] to establish VPLS service, i.e., for the auto-discovery of VPLS 
members and for the setup and teardown of the pseudowires that 
constitute a given VPLS instance. Section 3 focuses on this, and 
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also describes how a VPLS that spans Autonomous System boundaries is 
set up, as well as how multi-homing is handled. Using BGP as the 
control plane for VPNs is not new (see [14], [6], and [11]): what is 
described here is based on the mechanisms proposed in [6]. 


The forwarding plane and the actions that a participating Provider 
Edge (PE) router offering the VPLS service must take is described in 
Section 4. 
In Section 5, the notion of 'decoupled” operation is defined, and the 
interaction of decoupled and non-decoupled PEs is described. 
Decoupling allows for more flexible deployment of VPLS. 

1.2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 


2. Functional Model 


This will be described with reference to the following figure. 


/ Al \ 
---- CE1 | 
/ a SSS / | | 
| A2 CE2- / \ / PE1 \ / 
\ / \ / NI No ===-- 
---- ---PE2 Ly 
| ll We. Sear 
| Service Provider Network | Nay \ 
| | CE5 A5 | 
| — [ER / 
OR A: PE4_/ — ----- 
| u-PE | --PE3 / \ / 
[===] ===- -=== 
Zim / | ape rete 
/ \/ \ / \ CE = Customer Edge Device 
| A3 CE3 --CE4 A4 | PE = Provider Edge Router 
\ / \ ‘ u-PE = Layer 2 Aggregation 
=z=== ===> A<n> = Customer site n 


Figure 1: Example of a VPLS 
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2.1. Terminology 


Terminology similar to that in [6] is used: a Service Provider (SP) 
network with P (Provider-only) and PE (Provider Edge) routers, and 
customers with CE (Customer Edge) devices. Here, however, there is 
an additional concept, that of a "u-PE", a Layer 2 PE device used for 
Layer 2 aggregation. The notion of u-PE is described further in 
Section 5. PE and u-PE devices are "VPLS-aware", which means that 
they know that a VPLS service is being offered. The term "VE" refers 
to a VPLS edge device, which could be either a PE or a u-PE. 


In contrast, the CE device (which may be owned and operated by either 
the SP or the customer) is VPLS-unaware; as far as the CE is 
concerned, it is connected to the other CEs in the VPLS via a Layer 2 
switched network. This means that there should be no changes to a CE 
device, either to the hardware or the software, in order to offer 
VPLS. 


A CE device may be connected to a PE or a u-PE via Layer 2 switches 
that are VPLS-unaware. From a VPLS point of view, such Layer 2 
switches are invisible, and hence will not be discussed further. 
Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3 
devices; this will be discussed further in a later section. 


The term "demultiplexor" refers to an identifier in a data packet 
that identifies the VPLS to which the packet belongs as well as the 
ingress PE. In this document, the demultiplexor is an MPLS label. 


The term "VPLS" will refer to the service as well as a particular 
instantiation of the service (i.e., an emulated LAN); it should be 
clear from the context which usage is intended. 


2.2. Assumptions 


The Service Provider Network is a packet switched network. The PEs 
are assumed to be (logically) fully meshed with tunnels over which 
packets that belong to a service (such as VPLS) are encapsulated and 
forwarded. These tunnels can be IP tunnels, such as Generic Routing 
Encapsulation (GRE), or MPLS tunnels, established by Resource 
Reservation Protocol - Traffic Engineering (RSVP-TE) or LDP. These 
tunnels are established independently of the services offered over 
them; the signaling and establishment of these tunnels are not 
discussed in this document. 


"Flooding" and MAC address "learning" (see Section 4) are an integral 
part of VPLS. However, these activities are private to an SP device, 
i.e., in the VPLS described below, no SP device requests another SP 
device to flood packets or learn MAC addresses on its behalf. 
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All the PEs participating in a VPLS are assumed to be fully meshed in 
the data plane, i.e., there is a bidirectional pseudowire between 
every pair of PEs participating in that VPLS, and thus every 
(ingress) PE can send a VPLS packet to the egress PE(s) directly, 
without the need for an intermediate PE (see Section 4.2.5.) This 
requires that VPLS PEs are logically fully meshed in the control 
plane so that a PE can send a message to another PE to set up the 
necessary pseudowires. See Section 3.6 for a discussion on 
alternatives to achieve a logical full mesh in the control plane. 


2.3. Interactions 


VPLS is a "LAN Service" in that CE devices that belong to a given 
VPLS instance V can interact through the SP network as if they were 
connected by a LAN. VPLS is "private" in that CE devices that belong 
to different VPLSs cannot interact. VPLS is "virtual" in that 
multiple VPLSs can be offered over a common packet switched network. 


PE devices interact to "discover" all the other PEs participating in 
the same VPLS, and to exchange demultiplexors. These interactions 
are control-driven, not data-driven. 


u-PEs interact with PEs to establish connections with remote PEs or 
u-PEs in the same VPLS. This interaction is control-driven. 


PE devices can participate simultaneously in both VPLS and IP VPNs 
[6]. These are independent services, and the information exchanged 
for each type of service is kept separate as the Network Layer 
Reachability Information (NLRI) used for this exchange has different 
Address Family Identifiers (AFIs) and Subsequent Address Family 
Identifiers (SAFIs). Consequently, an implementation MUST maintain a 
separate routing storage for each service. However, multiple 
services can use the same underlying tunnels; the VPLS or VPN label 
is used to demultiplex the packets belonging to different services. 


3. Control Plane 


There are two primary functions of the VPLS control plane: auto- 
discovery, and setup and teardown of the pseudowires that constitute 
the VPLS, often called signaling. Section 3.1 and Section 3.2 
describe these functions. Both of these functions are accomplished 
with a single BGP Update advertisement; Section 3.3 describes how 
this is done by detailing BGP protocol operation for VPLS. 

Section 3.4 describes the setting up of pseudowires that span 
Autonomous Systems. Section 3.5 describes how multi-homing is 
handled. 
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3.1. Auto-Discovery 


Discovery refers to the process of finding all the PEs that 
participate in a given VPLS instance. A PE either can be configured 
with the identities of all the other PEs in a given VPLS or can use 
some protocol to discover the other PEs. The latter is called auto- 
discovery. 


The former approach is fairly configuration-intensive, especially 
since it is required that the PEs participating in a given VPLS are 
fully meshed (i.e., that every PE in a given VPLS establish 
pseudowires to every other PE in that VPLS). Furthermore, when the 
topology of a VPLS changes (i.e., a PE is added to, or removed from, 
the VPLS), the VPLS configuration on all PEs in that VPLS must be 
changed. 


In the auto-discovery approach, each PE "discovers" which other PEs 
are part of a given VPLS by means of some protocol, in this case BGP. 
This allows each PE’s configuration to consist only of the identity 
of the VPLS instance established on this PE, not the identity of 
every other PE in that VPLS instance -- that is auto-discovered. 
Moreover, when the topology of a VPLS changes, only the affected PE's 
configuration changes; other PEs automatically find out about the 
change and adapt. 


3.1.1. Functions 


A PE that participates in a given VPLS instance V must be able to 
tell all other PEs in VPLS V that it is also a member of V. A PE 
must also have a means of declaring that it no longer participates in 
a VPLS. To do both of these, the PE must have a means of identifying 
a VPLS and a means by which to communicate to all other PEs. 


U-PE devices also need to know what constitutes a given VPLS; 
however, they don’t need the same level of detail. The PE (or PEs) 


to which a u-PE is connected gives the u-PE an abstraction of the 
VPLS; this is described in Section 5. 


3.1.2. Protocol Specification 


The specific mechanism for auto-discovery described here is based on 


[14] and [6]; it uses BGP extended communities [5] to identify 
members of a VPLS, in particular, the Route Target community, whose 
format is described in [5]. The semantics of the use of Route 


Targets is described in [6]; their use in VPLS is identical. 
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As it has been assumed that VPLSs are fully meshed, a single Route 
Target RT suffices for a given VPLS V, and in effect that RT is the 
identifier for VPLS V. 


A PE announces (typically via I-BGP) that it belongs to VPLS V by 
annotating its NLRIs for V (see next subsection) with Route Target 
RT, and acts on this by accepting NLRIs from other PEs that have 
Route Target RT. A PE announces that it no longer participates in V 
by withdrawing all NLRIs that it had advertised with Route Target RT. 


Signaling 


Once discovery is done, each pair of PEs in a VPLS must be able to 
establish (and tear down) pseudowires to each other, i.e., exchange 
(and withdraw) demultiplexors. This process is known as signaling. 
Signaling is also used to transmit certain characteristics of the 
pseudowires that a PE sets up for a given VPLS. 


Recall that a demultiplexor is used to distinguish among several 
different streams of traffic carried over a tunnel, each stream 
possibly representing a different service. In the case of VPLS, the 
demultiplexor not only says to which specific VPLS a packet belongs, 
but also identifies the ingress PE. The former information is used 
for forwarding the packet; the latter information is used for 
learning MAC addresses. The demultiplexor described here is an MPLS 
label. However, note that the PE-to-PE tunnels need not be MPLS 
tunnels. 


Using a distinct BGP Update message to send a demultiplexor to each 
remote PE would require the originating PE to send N such messages 
for N remote PEs. The solution described in this document allows a 
PE to send a single (common) Update message that contains 
demultiplexors for all the remote PEs, instead of N individual 
messages. Doing this reduces the control plane load both on the 
originating PE as well as on the BGP Route Reflectors that may be 
involved in distributing this Update to other PEs. 


1. Label Blocks 


To accomplish this, we introduce the notion of "label blocks". A 
label block, defined by a label base LB and a VE block size VBS, is a 
contiguous set of labels {LB, LB+1, ..., LB+VBS-1). Here's how label 
blocks work. All PEs within a given VPLS are assigned unique VE IDs 
as part of their configuration. A PE X wishing to send a VPLS update 
sends the same label block information to all other PEs. Each 
receiving PE infers the label intended for PE X by adding its 
(unique) VE ID to the label base. In this manner, each receiving PE 
gets a unique demultiplexor for PE X for that VPLS. 
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This simple notion is enhanced with the concept of a VE block offset 
VBO. A label block defined by <LB, VBO, VBS> is the set {LB+VBO, 
LB+VBO+1, ..., LB+VBO+VBS-1). Thus, instead of a single large label 
block to cover all VE IDs in a VPLS, one can have several label 
blocks, each with a different label base. This makes label block 
management easier, and also allows PE X to cater gracefully to a PE 
joining a VPLS with a VE ID that is not covered by the set of label 
blocks that PE X has already advertised. 


When a PE starts up, or is configured with a new VPLS instance, the 
BGP process may wish to wait to receive several advertisements for 
that VPLS instance from other PEs to improve the efficiency of label 
block allocation. 


3.2.2. VPLS BGP NLRI 


The VPLS BGP NLRI described below, with a new AFI and SAFI (see [4]) 
is used to exchange VPLS membership and demultiplexors. 


A VPLS BGP NLRI has the following information elements: a VE ID, a VE 
Block Offset, a VE Block Size, and a label base. The format of the 
VPLS NLRI is given below. The AFI is the L2VPN AFI (25), and the 


SAFI is the VPLS SAFI (65). The Length field is in octets. 
HOZ + 
| Length (2 octets) | 
$------------------------------------ + 
| Route Distinguisher (8 octets) | 
$------------------------------------ + 
| VE ID (2 octets) | 
$------------------------------------ + 
| VE Block Offset (2 octets) | 
HO + 
| VE Block Size (2 octets) | 
$------------------------------------ + 
| Label Base (3 octets) | 
HO + 


Figure 2: BGP NLRI for VPLS Information 


A PE participating in a VPLS must have at least one VE ID. If the PE 
is the VE, it typically has one VE ID. If the PE is connected to 
several u-PEs, it has a distinct VE ID for each u-PE. It may 
additionally have a VE ID for itself, if it itself acts as a VE for 
that VPLS. In what follows, we will call the PE announcing the VPLS 
NLRI PE-a, and we will assume that PE-a owns VE ID V (either 
belonging to PE-a itself or to a u-PE connected to PE-a). 
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VE IDs are typically assigned by the network administrator. Their 
scope is local to a VPLS. A given VE ID should belong to only one 
PE, unless a CE is multi-homed (see Section 3.5). 


A label block is a set of demultiplexor labels used to reach a given 
VE ID. A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block 
Size VBS, and label base LB communicates to its peers the following: 


label block for V: labels from LB to (LB + VBS - 1), and 


remote VE set for V: from VBO to (VBO + VBS - 1). 


There is a one-to-one correspondence between the remote VE set and 
the label block: VE ID (VBO + n) corresponds to label (LB + n). 


3.2.3. PW Setup and Teardown 


Suppose PE-a is part of VPLS foo and makes an announcement with VE ID 
V, VE Block Offset VBO, VE Block Size VBS, and label base LB. If 
PE-b is also part of VPLS foo and has VE ID W, PE-b does the 
following: 


1. checks if W is part of PE-a’s 'remote VE set’: if VBO <= W < VBO 
+ VBS, then W is part of PE-a’s remote VE set. If not, PE-b 
ignores this message, and skips the rest of this procedure. 


2. sets up a PW to PE-a: the demultiplexor label to send traffic 
from PE-b to PE-a is computed as (LB + W - VBO). 


3. checks if V is part of any ’remote VE set’ that PE-b announced, 
i.e., PE-b checks if V belongs to some remote VE set that PE-b 
announced, say with VE Block Offset VBO’, VE Block Size VBS’, and 
label base LB’. If not, PE-b MUST make a new announcement as 
described in Section 3.3. 


4. sets up a PW from PE-a: the demultiplexor label over which PE-b 
should expect traffic from PE-a is computed as: (LB’ + V - VBO’). 


If Y withdraws an NLRI for V that X was using, then X MUST tear down 
its ends of the pseudowire between X and Y. 


3.2.4. Signaling PE Capabilities 


The following extended attribute, the "Layer2 Info Extended 
Community", is used to signal control information about the 
pseudowires to be setup for a given VPLS. The extended community 
value is to be allocated by IANA (currently used value is 0x800A). 
This information includes the Encaps Type (type of encapsulation on 
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the pseudowires), Control Flags (control information regarding the 
pseudowires), and the Maximum Transmission Unit (MTU) to be used on 
the pseudowires. 


The Encaps Type for VPLS is 19. 


$------------------------------------ + 
| Extended community type (2 octets) | 
pooti eee SS eee E + 
| Encaps Type (1 octet) | 
$o------------------- ~~~ +--+ + 
| Control Flags (1 octet) 

fee et ee he ae ae eee eS + 
| Layer-2 MTU (2 octet) | 
Sy ~~~ +--+ + 
| Reserved (2 octets) | 
+--------------------------------- + 


Figure 3: Layer2 Info Extended Community 


01234567 
+-+-+-+-+-+-+-+-+ 
| MBZ |c|s| (MBZ = MUST Be Zero) 
+-+-+-+-+-+-+-+-+ 


Figure 4: Control Flags Bit Vector 


With reference to Figure 4, the following bits in the Control Flags 
are defined; the remaining bits, designated MBZ, MUST be set to zero 
when sending and MUST be ignored when receiving this community. 


Name Meaning 


C A Control word [7] MUST or MUST NOT be present when 
sending VPLS packets to this PE, depending on whether C 
is 1 or 0, respectively 


S Sequenced delivery of frames MUST or MUST NOT be used 
when sending VPLS packets to this PE, depending on 
whether S is 1 or 0, respectively 


II BGP VPLS Operation 
To create a new VPLS, say VPLS foo, a network administrator must pick 
an RT for VPLS foo, say RT-foo. This will be used by all PEs that 


serve VPLS foo. To configure a given PE, say PE-a, to be part of 
VPLS foo, the network administrator only has to choose a VE ID V for 
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PE-a. (If PE-a is connected to u-PEs, PE-a may be configured with 
more than one VE ID; in that case, the following is done for each VE 
ID). The PE may also be configured with a Route Distinguisher (RD); 


if not, it generates a unique RD for VPLS foo. Say the RD is 
RD-foo-a. PE-a then generates an initial label block and a remote VE 
set for V, defined by VE Block Offset VBO, VE Block Size VBS, and 
label base LB. These may be empty. 


PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block 
Offset VBO, VE Block Size VBS and label base LB. To this, it 
attaches a Layer2 Info Extended Community and an RT, RT-foo. It sets 
the BGP Next Hop for this NLRI as itself, and announces this NLRI to 
its peers. The Network Layer protocol associated with the Network 
Address of the Next Hop for the combination <AFI=L2VPN AFI, SAFI=VPLS 
SAFI> is IP; this association is required by [4], Section 5. If the 
value of the Length of the Next Hop field is 4, then the Next Hop 
contains an IPv4 address. If this value is 16, then the Next Hop 
contains an IPv6 address. 


If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with 
RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same 


VPLS (auto-discovery). PE-a then has to set up its part of a VPLS 
pseudowire between PE-a and PE-b, using the mechanisms in 
Section 3.2. Similarly, PE-b will have discovered that PE-a is in 


the same VPLS, and PE-b must set up its part of the VPLS pseudowire. 
Thus, signaling and pseudowire setup is also achieved with the same 
Update message. 


If W is not in any remote VE set that PE-a announced for VE ID V in 
VPLS foo, PE-b will not be able to set up its part of the pseudowire 
to PE-a. To address this, PE-a can choose to withdraw the old 
announcement (s) it made for VPLS foo, and announce a new Update with 
a larger remote VE set and corresponding label block that covers all 
VE IDs that are in VPLS foo. This, however, may cause some service 
disruption. An alternative for PE-a is to create a new remote VE set 
and corresponding label block, and announce them in a new Update, 
without withdrawing previous announcements. 


If PE-a’s configuration is changed to remove VE ID V from VPLS foo, 
then PE-a MUST withdraw all its announcements for VPLS foo that 
contain VE ID V. If all of PE-a's links to its CEs in VPLS foo go 
down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo or 
let other PEs in the VPLS foo know in some way that PE-a is no longer 
connected to its CEs. 
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3.4. Multi-AS VPLS 


As in [14] and [6], the above auto-discovery and signaling functions 
are typically announced via I-BGP. This assumes that all the sites 
in a VPLS are connected to PEs in a single Autonomous System (AS). 


However, sites in a VPLS may connect to PEs in different ASes. This 
leads to two issues: 1) there would not be an I-BGP connection 
between those PEs, so some means of signaling across ASes is needed; 
and 2) there may not be PE-to-PE tunnels between the ASes. 


A similar problem is solved in [6], Section 10. Three methods are 
suggested to address issue (1); all these methods have analogs in 


multi-AS VPLS. 


Here is a diagram for reference: 


/ \ / \ / \ / \ 
Nun} AS 1 \ / AS 2 NL 
Le 
+----- + +------—- + | +------- + +----- + 
PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | 
4===-- + +------—- + | +------- + +----—- + 
Paes IN E 
eN 2O Z 
\ / \ / \ / \ / 


Figure 5: Inter-AS VPLS 


As in the above reference, three methods for signaling inter-provider 
VPLS are given; these are presented in order of increasing 
scalability. Method (a) is the easiest to understand conceptually, 
and the easiest to deploy; however, it requires an Ethernet 
interconnect between the ASes, and both VPLS control and data plane 


state on the AS border routers (ASBRs). Method (b) requires VPLS 
control plane state on the ASBRs and MPLS on the AS-AS interconnect 
(which need not be Ethernet). Method (c) requires MPLS on the AS-AS 


interconnect, but no VPLS state of any kind on the ASBRs. 
3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs 


In this method, an AS Border Router (ASBR1) acts as a PE for all 
VPLSs that span AS1 and an AS to which ASBR1 is connected, such as 
AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1 
as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as 
a PE for this VPLS from AS2's point of view, and views ASBRI as a CE. 


Kompella & Rekhter Standards Track [Page 13] 


RFC 4761 BGP Auto-Discovery and Signaling for VPLS January 2007 


This method does not require MPLS on the ASBR1-ASBR2 link, but does 
require that this link carry Ethernet traffic and that there be a 
separate VLAN sub-interface for each VPLS traversing this link. It 
further requires that ASBR1 does the PE operations (discovery, 
signaling, MAC address learning, flooding, encapsulation, etc.) for 
all VPLSs that traverse ASBR1. This imposes a significant burden on 
ASBR1, both on the control plane and the data plane, which limits the 
number of multi-AS VPLSs. 


Note that in general, there will be multiple connections between a 
pair of ASes, for redundancy. In this case, the Spanning Tree 
Protocol (STP) [15], or some other means of loop detection and 
prevention, must be run on each VPLS that spans these ASes, so that a 
loop-free topology can be constructed in each VPLS. This imposes a 
further burden on the ASBRs and PES participating in those VPLSs, as 
these devices would need to run a loop detection algorithm for each 
such VPLS. How this may be achieved is outside the scope of this 
document. 


3.4.2. Method (b): EBGP Redistribution of VPLS Information between 
ASBRs 


This method requires I-BGP peerings between the PEs in AS1 and ASBR1 
in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1 
and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in 
AS2. In the above example, PE1l sends a VPLS NLRI to ASBR1 with a 
label block and itself as the BGP nexthop; ASBR1 sends the NLRI to 
ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends 
the NLRI to PE2 with new labels and itself as the nexthop. 
Correspondingly, there are three tunnels: T1 from PEl to ASBR1, T2 
from ASBR1 to ASBR2, and T3 from ASBR2 to PE2. Within each tunnel, 
the VPLS label to be used is determined by the receiving device; 
e.g., the VPLS label within Tl is a label from the label block that 
ASBR1 sent to PEl. The ASBRs are responsible for receiving VPLS 
packets encapsulated in a tunnel and performing the appropriate label 
swap operations described next so that the next receiving device can 
correctly identify and forward the packet. 


The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 
sends to PE2) is identical to the VPLS NLRI that PEl sends to ASBRI, 
except for the label block. To be precise, the Length, the Route 
Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size 
MUST be the same; the Label Base may be different. Furthermore, 
ASBR1 must also update its forwarding path as follows: if the Label 
Base sent by PE1 is L1, the Label-block Size is N, the Label Base 
sent by ASBR1 is L2, and the tunnel label from ASBR1 to PEl is T, 
then ASBR1 must install the following in the forwarding path: 
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3: 


4. 


swap L2 with L1 and push T, 
swap L2+1 with L1+1 and push T, 
swap L2+N-1 with L1+N-1 and push T. 


ASBR2 must act similarly, except that it may not need a tunnel label 
if it is directly connected with ASBR1. 


When PE2 wants to send a VPLS packet to PEl, PE2 uses its VE ID to 
get the right VPLS label from ASBR2’s label block for PE1, and uses a 
tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the 
label from ASBR1; ASBR1 then swaps the VPLS label with the label from 
PE1, and pushes a tunnel label to reach PEl. 


In this method, one needs MPLS on the ASBR1-ASBR2 interface, but 
there is no requirement that the link layer be Ethernet. 
Furthermore, the ASBRs take part in distributing VPLS information. 
However, the data plane requirements of the ASBRs are much simpler 
than in method (a), being limited to label operations. Finally, the 
construction of loop-free VPLS topologies is done by routing 
decisions, viz. BGP path and nexthop selection, so there is no need 
to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this 
method is considerably more scalable than method (a). 


3. Method (c): Multi-Hop EBGP Redistribution of VPLS Information 
between ASes 


In this method, there is a multi-hop E-BGP peering between the PEs 
(or preferably, a Route Reflector) in AS1 and the PEs (or Route 
Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop 
self to PE2; if this is via route reflectors, the BGP nexthop is not 
changed. This requires that there be a tunnel LSP from PE1 to PE2. 
This tunnel LSP can be created exactly as in [6], Section 10 (c), for 
example using E-BGP to exchange labeled IPv4 routes for the PE 
loopbacks. 


When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label 
corresponding to its own VE ID onto the packet. It then pushes the 
tunnel label(s) to reach PE2. 


This method requires no VPLS information (in either the control or 
the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE 
tunnel LSPs in the control plane, and do label operations in the data 
plane. Again, as in the case of method (b), the construction of 
loop-free VPLS topologies is done by routing decisions, i.e., BGP 
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path and nexthop selection, so there is no need to run the Spanning 
Tree Protocol on a per-VPLS basis. This option is likely to be the 
most scalable of the three methods presented here. 


3.4.4. Allocation of VE IDs across Multiple ASes 


In order to ease the allocation of VE IDs for a VPLS that spans 
multiple ASes, one can allocate ranges for each AS. For example, AS1 
uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If 
there are 10 sites attached to AS1 and 20 to AS2, the allocated VE 
IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS 
NLRIs that are exchanged while ensuring that VE IDs are kept unique. 


In the above example, if AS1 needed more than 100 sites, then another 
range can be allocated to AS1. The only caveat is that there be no 
overlap between VE ID ranges among ASes. The exception to this rule 
is multi-homing, which is dealt with below. 


3.5. Multi-homing and Path Selection 


It is often desired to multi-home a VPLS site, i.e., to connect it to 
multiple PEs, perhaps even in different ASes. In such a case, the 
PEs connected to the same site can be configured either with the same 
VE ID or with different VE IDs. In the latter case, it is mandatory 
to run STP on the CE device, and possibly on the PEs, to construct a 
loop-free VPLS topology. How this can be accomplished is outside the 
scope of this document; however, the rest of this section will 
describe in some detail the former case. Note that multi-homing by 
the SP and STP on the CEs can co-exist; thus, it is recommended that 
the VPLS customer run STP if the CEs are able to. 


In the case where the PEs connected to the same site are assigned the 
same VE ID, a loop-free topology is constructed by routing 
mechanisms, in particular, by BGP path selection. When a BGP speaker 
receives two equivalent NLRIs (see below for the definition), it 
applies standard path selection criteria such as Local Preference and 
AS Path Length to determine which NLRI to choose; it MUST pick only 
one. If the chosen NLRI is subsequently withdrawn, the BGP speaker 
applies path selection to the remaining equivalent VPLS NLRIs to pick 
another; if none remain, the forwarding information associated with 
that NLRI is removed. 


Two VPLS NLRIs are considered equivalent from a path selection point 
of view if the Route Distinguisher, the VE ID, and the VE Block 
Offset are the same. If two PES are assigned the same VE ID ina 
given VPLS, they MUST use the same Route Distinguisher, and they 
SHOULD announce the same VE Block Size for a given VE Offset. 
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3.6. Hierarchical BGP VPLS 


This section discusses how one can scale the VPLS control plane when 


using BGP. There are at least three aspects of scaling the control 

plane: 

1. alleviating the full mesh connectivity requirement among VPLS BGP 
speakers; 


2. limiting BGP VPLS message passing to just the interested speakers 
rather than all BGP speakers; and 


3. simplifying the addition and deletion of BGP speakers, whether 
for VPLS or other applications. 


Fortunately, the use of BGP for Internet routing as well as for IP 
VPNs has yielded several good solutions for all these problems. The 
basic technique is hierarchy, using BGP Route Reflectors (RRs) [8]. 
The idea is to designate a small set of Route Reflectors that are 
themselves fully meshed, and then establish a BGP session between 
each BGP speaker and one or more RRs. In this way, there is no need 
for direct full mesh connectivity among all the BGP speakers. If the 
particular scaling needs of a provider require a large number of RRs, 
then this technique can be applied recursively: the full mesh 
connectivity among the RRs can be brokered by yet another level of 
RRs. The use of RRs solves problems 1 and 3 above. 


It is important to note that RRs, as used for VPLS and VPNs, are 
purely a control plane technique. The use of RRs introduces no data 
plane state and no data plane forwarding requirements on the RRs, and 
does not in any way change the forwarding path of VPLS traffic. This 
is in contrast to the technique of Hierarchical VPLS defined in [10]. 


Another consequence of this approach is that it is not required that 
one set of RRs handles all BGP messages, or that a particular RR 
handle all messages from a given PE. One can define several sets of 
RRs, for example, a set to handle VPLS, another to handle IP VPNs, 
and another for Internet routing. Another partitioning could be to 
have some subset of VPLSs and IP VPNs handled by one set of RRs, and 
another subset of VPLSs and IP VPNs handled by another set of RRs; 
the use of Route Target Filtering (RTF), described in [12], can make 
this simpler and more effective. 


Finally, problem 2 (that of limiting BGP VPLS message passing to just 
the interested BGP speakers) is addressed by the use of RTF. This 
technique is orthogonal to the use of RRs, but works well in 
conjunction with RRs. RTF is also very effective in inter-AS VPLS; 
more details on how RTF works and its benefits are provided in [12]. 
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It is worth mentioning an aspect of the control plane that is often a 
source of confusion. No MAC addresses are exchanged via BGP. All 
MAC address learning and aging is done in the data plane individually 
by each PE. The only task of BGP VPLS message exchange is auto- 
discovery and label exchange. 


Thus, BGP processing for VPLS occurs when 
1. a PE joins or leaves a VPLS; or 


2. a failure occurs in the network, bringing down a PE-PE tunnel or 
a PE-CE link. 


These events are relatively rare, and typically, each such event 
causes one BGP update to be generated. Coupled with BGP’s messaging 
efficiency when used for signaling VPLS, these observations lead to 
the conclusion that BGP as a control plane for VPLS will scale quite 
well in terms of both processing and memory requirements. 


4. Data Plane 


This section discusses two aspects of the data plane for PEs and 
u-PEs implementing VPLS: encapsulation and forwarding. 


4.1. Encapsulation 


Ethernet frames received from CE devices are encapsulated for 


transmission over the packet switched network connecting the PEs. 
The encapsulation is as in [7]. 


4.2. Forwarding 


VPLS packets are classified as belonging to a given service instance 
and associated forwarding table based on the interface over which the 
packet is received. Packets are forwarded in the context of the 
service instance based on the destination MAC address. The former 


mapping is determined by configuration. The latter is the focus of 
this section. 


4.2.1. MAC Address Learning 


As was mentioned earlier, the key distinguishing feature of VPLS is 
that it is a multipoint service. This means that the entire Service 
Provider network should appear as a single logical learning bridge 
for each VPLS that the SP network supports. The logical ports for 
the SP "bridge" are the customer ports as well as the pseudowires on 
a VE. Just as a learning bridge learns MAC addresses on its ports, 
the SP bridge must learn MAC addresses at its VEs. 
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Learning consists of associating source MAC addresses of packets with 
the (logical) ports on which they arrive; this association is the 
Forwarding Information Base (FIB). The FIB is used for forwarding 
packets. For example, suppose the bridge receives a packet with 
source MAC address S on (logical) port P. If subsequently, the 
bridge receives a packet with destination MAC address S, it knows 
that it should send the packet out on port P. 


If a VE learns a source MAC address S on logical port P, then later 
sees S on a different port P’, then the VE MUST update its FIB to 
reflect the new port P’. A VE MAY implement a mechanism to damp 
flapping of source ports for a given MAC address. 


Tj ~ 


4.2.2. Aging 


VPLS PEs SHOULD have an aging mechanism to remove a MAC address 
associated with a logical port, much the same as learning bridges do. 
This is required so that a MAC address can be relearned if it "moves" 
from a logical port to another logical port, either because the 
station to which that MAC address belongs really has moved or because 
of a topology change in the LAN that causes this MAC address to 
arrive on a new port. In addition, aging reduces the size of a VPLS 
MAC table to just the active MAC addresses, rather than all MAC 
addresses in that VPLS. 


The "age" of a source MAC address S on a logical port P is the time 
since it was last seen as a source MAC on port P. If the age exceeds 
the aging time T, S MUST be flushed from the FIB. This of course 
means that every time S is seen as a source MAC address on port P, 
S’s age is reset. 


An implementation SHOULD provide a configurable knob to set the aging 
time T on a per-VPLS basis. In addition, an implementation MAY 
accelerate aging of all MAC addresses in a VPLS if it detects certain 
situations, such as a Spanning Tree topology change in that VPLS. 


4.2.3. Flooding 


When a bridge receives a packet to a destination that is not in its 
FIB, it floods the packet on all the other ports. Similarly, a VE 
will flood packets to an unknown destination to all other VEs in the 
VPLS. 


In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the 


destination MAC address on the frame was not in PE2’s FIB (for that 
VPLS), then PE2 would be responsible for flooding that frame to every 
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other PE in the same VPLS. On receiving that frame, PEl would be 
responsible for further flooding the frame to CEl and CE5 (unless PEl 
knew which CE "owned" that MAC address). 


On the other hand, if PE3 received the frame, it could delegate 
further flooding of the frame to its u-PE. If PE3 was connected to 
two u-PEs, it would announce that it has two u-PEs. PE3 could either 
announce that it is incapable of flooding, in which case it would 
receive two frames, one for each u-PE, or it could announce that it 
is capable of flooding, in which case it would receive one copy of 
the frame, which it would then send to both u-PEs. 


4.2.4. Broadcast and Multicast 


There is a well-known broadcast MAC address. An Ethernet frame whose 
destination MAC address is the broadcast MAC address must be sent to 
all stations in that VPLS. This can be accomplished by the same 
means that is used for flooding. 


There is also an easily recognized set of "multicast" MAC addresses. 
Ethernet frames with a destination multicast MAC address MAY be 
broadcast to all stations; a VE MAY also use certain techniques to 
restrict transmission of multicast frames to a smaller set of 
receivers, those that have indicated interest in the corresponding 
multicast group. Discussion of this is outside the scope of this 
document. 


4.2.5. “Split Horizon" Forwarding 


When a PE capable of flooding (say PEx) receives a broadcast Ethernet 
frame, or one with an unknown destination MAC address, it must flood 
the frame. If the frame arrived from an attached CE, PEx must send a 
copy of the frame to every other attached CE, as well as to all other 
PES participating in the VPLS. If, on the other hand, the frame 
arrived from another PE (say PEy), PEx must send a copy of the packet 
only to attached CEs. PEx MUST NOT send the frame to other PEs, 
since PEy would have already done so. This notion has been termed 
"split horizon" forwarding and is a consequence of the PEs being 
logically fully meshed for VPLS. 


Split horizon forwarding rules apply to broadcast and multicast 
packets, as well as packets to an unknown MAC address. 
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4 


4 


-2.6. Qualified and Unqualified Learning 


The key for normal Ethernet MAC learning is usually just the 
(6-octet) MAC address. This is called "unqualified learning". 
However, it is also possible that the key for learning includes the 
VLAN tag when present; this is called "qualified learning". 


In the case of VPLS, learning is done in the context of a VPLS 
instance, which typically corresponds to a customer. If the customer 
uses VLAN tags, one can make the same distinctions of qualified and 
unqualified learning. If the key for learning within a VPLS is just 
the MAC address, then this VPLS is operating under unqualified 
learning. If the key for learning is (customer VLAN tag + MAC 
address), then this VPLS is operating under qualified learning. 


Choosing between qualified and unqualified learning involves several 
factors, the most important of which is whether one wants a single 
global broadcast domain (unqualified) or a broadcast domain per VLAN 
(qualified). The latter makes flooding and broadcasting more 
efficient, but requires larger MAC tables. These considerations 
apply equally to normal Ethernet forwarding and to VPLS. 


.2.7. Class of Service 


In order to offer different Classes of Service within a VPLS, an 
implementation MAY choose to map 802.1p bits in a customer Ethernet 
frame with a VLAN tag to an appropriate setting of EXP bits in the 
pseudowire and/or tunnel label, allowing for differential treatment 
of VPLS frames in the packet switched network. 


To be useful, an implementation SHOULD allow this mapping function to 
be different for each VPLS, as each VPLS customer may have its own 
view of the required behavior for a given setting of 802.1p bits. 


Deployment Options 


In deploying a network that supports VPLS, the SP must decide what 
functions the VPLS-aware device closest to the customer (the VE) 
supports. The default case described in this document is that the VE 
is a PE. However, there are a number of reasons that the VE might be 
a device that does all the Layer 2 functions (such as MAC address 
learning and flooding), and a limited set of Layer 3 functions (such 
as communicating to its PE), but, for example, doesn’t do full- 
fledged discovery and PE-to-PE signaling. Such a device is called a 
"u-PE " N 
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As both of these cases have benefits, one would like to be able to 
"mix and match" these scenarios. The signaling mechanism presented 
here allows this. For example, in a given provider network, one PE 
may be directly connected to CE devices, another may be connected to 
u-PEs that are connected to CEs, and a third may be connected 
directly to a customer over some interfaces and to u-PEs over others. 
All these PEs perform discovery and signaling in the same manner. 
How they do learning and forwarding depends on whether or not there 
is a u-PE; however, this is a local matter, and is not signaled. 
However, the details of the operation of a u-PE and its interactions 
with PEs and other u-PEs are beyond the scope of this document. 


6. Security Considerations 


The focus in Virtual Private LAN Service is the privacy of data, 
i.e., that data in a VPLS is only distributed to other nodes in that 
VPLS and not to any external agent or other VPLS. Note that VPLS 
does not offer confidentiality, integrity, or authentication: VPLS 
packets are sent in the clear in the packet switched network, and a 
man-in-the-middle can eavesdrop, and may be able to inject packets 
into the data stream. If security is desired, the PE-to-PE tunnels 
can be IPsec tunnels. For more security, the end systems in the VPLS 
sites can use appropriate means of encryption to secure their data 
even before it enters the Service Provider network. 


There are two aspects to achieving data privacy in a VPLS: securing 
the control plane and protecting the forwarding path. Compromise of 
the control plane could result in a PE sending data belonging to some 
VPLS to another VPLS, or blackholing VPLS data, or even sending it to 
an eavesdropper; none of which are acceptable from a data privacy 
point of view. Since all control plane exchanges are via BGP, 
techniques such as in [2] help authenticate BGP messages, making it 
harder to spoof updates (which can be used to divert VPLS traffic to 
the wrong VPLS) or withdraws (denial-of-service attacks). In the 
multi-AS methods (b) and (c) described in Section 3, this also means 
protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or 
the Route Reflectors. One can also use the techniques described in 
Section 10 (b) and (c) of [6], both for the control plane and the 
data plane. Note that [2] will not help in keeping VPLS labels 
private -- knowing the labels, one can eavesdrop on VPLS traffic. 
However, this requires access to the data path within a Service 
Provider network. 


There can also be misconfiguration leading to unintentional 
connection of CEs in different VPLSs. This can be caused, for 
example, by associating the wrong Route Target with a VPLS instance. 
This problem, shared by [6], is for further study. 
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Protecting the data plane requires ensuring that PE-to-PE tunnels are 
well-behaved (this is outside the scope of this document), and that 
VPLS labels are accepted only from valid interfaces. For a PE, valid 
interfaces comprise links from P routers. For an ASBR, a valid 
interface is a link from an ASBR in an AS that is part of a given 
VPLS. It is especially important in the case of multi-AS VPLSs that 
one accept VPLS packets only from valid interfaces. 


MPLS-in-IP and MPLS-in-GRE tunneling are specified in [3]. If it is 
desired to use such tunnels to carry VPLS packets, then the security 
considerations described in Section 8 of that document must be fully 
understood. Any implementation of VPLS that allows VPLS packets to 
be tunneled as described in that document MUST contain an 
implementation of IPsec that can be used as therein described. If 
the tunnel is not secured by IPsec, then the technique of IP address 
filtering at the border routers, described in Section 8.2 of that 
document, is the only means of ensuring that a packet that exits the 
tunnel at a particular egress PE was actually placed in the tunnel by 
the proper tunnel head node (i.e., that the packet does not have a 
spoofed source address). Since border routers frequently filter only 
source addresses, packet filtering may not be effective unless the 
egress PE can check the IP source address of any tunneled packet it 
receives, and compare it to a list of IP addresses that are valid 
tunnel head addresses. Any implementation that allows MPLS-in-IP 
and/or MPLS-in-GRE tunneling to be used without IPsec MUST allow the 
egress PE to validate in this manner the IP source address of any 
tunneled packet that it receives. 


7. IANA Considerations 


IANA allocated value (25) for AFI for L2VPN information. This should 
be the same as the AFI requested by [11]. 


IANA allocated an extended community value (0x800a) for the Layer2 
Info Extended Community. 
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